Subject: Network Management AP draft comments

From: "Michael O. Allen (919-254-4442)" <[email-masked]>
Date: Mon, 6 Jun 94 08:38:53 EDT

Ref:  My note of 31 May 1994, 15:31:13 EDT (attached)

Resending due to mail problems.

----------------------------- Note follows ------------------------------
Date: 31 May 1994, 15:31:13 EDT
From: Michael O. Allen          919-254-4442         MOALLEN  at RALVM6
      Open Architecture Development
      IBM Networking Systems
      Research Triangle Park, NC  27709
      Internet: [email-masked]
To:   Christine Martin                               cmm      at datcon.co.uk
cc:   aiw-dlur at ibmstandards.cary.ibm.com

Re:   Network Management AP draft comments
Ref:  Your note of Fri, 27 May 1994 17:12:31 +0100 (attached)

Christine,

Thank you for your prompt comments!  I have inserted responses below.

Regards,
Mike Allen

----------------------------- Note follows ------------------------------
From: [email-masked] (Christine Martin)
Date: Fri, 27 May 1994 17:12:31 +0100
X-Mailer: Mail User's Shell (7.2.4 2/2/92)
To: [email-masked]
Subject: Network Management AP draft comments
Cc: [email-masked], [email-masked], [email-masked]

Ed,

I've just looked over the Network Management AP Draft Document and have
a few comments.

1) Typo on page 4-2, last paragraph, "information that may be need for
   diagnostic..." probably should read "information that may be needed
   for diagnostic..."

>   Thanks, I will correct that.

2) On the top of page 4-3 there is a list of information that should be
   saved locally if a CP-SVR session is terminated abnormally.  The
   list includes Mode name - which by definition is CPSVRMGR mode.

>  You are correct, the mode name is redundant if the error log entry is
>  specifically for a DLUR-DLUS problem; however, I was thinking that
>  the information listed was really no different from what might be
>  recorded for any abnormal session end, so a special record type for
>  a CP-SVR session outage was not needed.  With that in mind, I should
>  have listed the data like this:
>
>     Date
>     Time
>     PLU name
>     SLU name
>     Mode name
>     Unbind type
>     Sense code
>     Detecting module name
>     Copy of any pertinent data (such as bad message unit received)
>     ...
>
>     (The PLU and SLU names will identify DLUR and DLUS).
>
>  Of course, this is just a recommendation of what a product should
>  record in its local error log, so you are certainly free to save
>  less or more information.

3) In the MIB definitions for the dlurNodeCapabilities the field
   dlurImplementationType appears with the choices dlur and dlus.
   Since the dlurNodeCapabilities is described as "information about
   the DLUR implementation" then this field seems redundant.

>  See next response.

4) Another field in this table, dlurTDUsupport indicates whether this node
   supports the receipt of TDUs.  By definition, the DLUR component does
   not support receipt of TDUs. (I am assuming that this field is referring
   to the DLUR specific capabilities and not the node as whole).

   Perhaps the dlurNodeCapabilities table is being designed for use by
   both DLUR and DLUS nodes.  If so, I would suggest a different name should
   be used.  The fields discussed in points 3 and 4 might then be relevant.
   Otherwise, these fields are unnecessary.

>  You are correct, these objects are redundant in a MIB designed for a
>  DLUR implementation.  I gave some brief thought to making the
>  dlurNodeCapabilities group generic enough to be applicable to a DLUS
>  implementation, as well; hence the presence of these objects.  But, in
>  the absence of any specific DLUS requirements, I should make this MIB
>  clearly DLUR-only.  I will delete these redundant objects.

5) Typo on page 4-9 in paragraph starting "The following.."  suplement
   should be supplement.

>  Thanks.

6) I'm unclear as to which DLUS the field dlurPuDlusSessnStatus
   of the dlurPuInfo table is referring to.  If the field is meant to
   describe whether there is an active DLUS associated with the PU then
   perhaps this field should be moved above the dlurPuActiveDlusName and
   dlurPuActiveDlusIndex fields.  (Although a null string in the
   dlurPuActiveDlusName field indicates that there is no active DLUS).
   If the field is meant to describe the session status of either the
   defined primary or backup DLUS nodes then the field definition should
   be clarified.

>    The dlurPuDlusSessnStatus object refers to the session with
>    dlurPuActiveDlusName.  I will update the description to make this
>    clear.  However, after thinking about this more and discussing it
>    with some of my peers here, I would like to propose dropping the
>    dlurPuActiveDlusIndex object entirely.  The rationale being that
>    keeping an index into the DLUS table (which may be non-trivial to
>    implement) has value only if we anticipate management applications
>    that will retrieve information about a single PU, and then use the
>    index to retrieve information about the specific DLUS upon which that
>    PU depends.  While that scenario is plausible, I think it is more
>    likely that we will see applications that retrieve and present
>    information about all the PUs at one time.  Information about the
>    DLUS other than that already shown in the PU table (DLUS name and
>    status) would be a separate retrieval, presumably for all the DLUS
>    entries at one time.  Given that scenario, I think that correlation
>    of PUs to DLUS by the DLUS name is adequate, especially since it is
>    likely that the number of DLUSs will be relatively small.  Opinions?

7) In the DlurDlusInfo table, the dlurDlusFRSNsent field is defined as
   "Flow reduction sequence number sent to the DLUS in CV51".  The CV51
   defines the field as "a value that identifies the latest TDU GDS
   variable received by the sender of the DLUR/S Capabilities CV from
   the receiver of the DLUR/S Capabilities CV".  Since the DLUR node
   never receives TDUs from the DLUS node, the field in the CV51 will
   always be set to 0.  Is the intention of this field to report the
   last FRSN sent to DLUS in a TDU?

>    Thanks for a very good point.  I had a long discussion about this
>    with Ed Tremblay, and I realize that I misunderstood the FRSN
>    processing in DLUR.  The FRSNs sent and received in CV51 are always
>    zero, so there is little value in having MIB objects to represent
>    them.  If we did keep track of the last FRSN sent in a TDU we would
>    have a non-zero value, but I don't see a strong case to add that to
>    the MIB:  it has little value in network operations (what would an
>    operator do if it were displayed?); it might have some value in
>    debugging protocol problems between DLUR and DLUS implementations,
>    but one would really need to trace the TDU exchanges in that
>    situation to understand what was happening.  So I am deleting both
>    the dlurDlusFRSNsent and dlurDlusFRSNreceived objects from the table.
>    Opinions?

8) In the DlurDlusInfo table, the dlurDlusTDUsupport field gives the
   TDU support indication received from the DLUS in CV51.  By definition,
   DLUS must support this.

>   You are correct.  I will delete this from the table.

9) Again, in the DlurDlusInfo table, I'm confused about the the
   dlurDlusANSsupport field.  I thought the CV51 bit this field is
   referring to are only set by the DLUR node and not relevant to the
   DLUS node.  Similarly, the dlurDlusMultiSubnetSupport field refers
   to a bit only relevant for DLUR to DLUS CV51 flows.

>   You are correct again on both points.  I will delete both objects
>   from this table.

Hope that input helps!

>   Yes, indeed!  Your input was quite helpful.

Christine

--
---===========================================================
Christine Martin  ([email-masked])
Data Connection Limited
Telephone: +44 81 366 1177
Fax:       +44 81 367 8501
---===========================================================